不会利用新版消息区的iOS开发者，小心掉进苹果审核的封号陷阱
⬆️ 欢迎戳蓝字关注
最近一直忙着写一些谷歌有关的话题，差一点就把今年计划要介绍的 itunes connect 的一个重大改版给遗漏了。
这个改版就是，审核区中的消息区的改造。
可能很多人对这次消息区的总体改动，感知不明显，因为大部分开发者，其实也没怎么去敏锐地通过审核区去解决过审和风险问题，因此我在这里简要的介绍一下。
现在苹果审核区的改版，不只是下面这个界面上的变化。
和过去相比，为了方便讲述，其中最核心的区别简单陈述就是：与苹果审核进行对话的上下文作用域变了。
怎么理解这句话的含义呢，例如说，过去开发者提交审核是这么一个模型。
开发者提审，进入状态审核中，被拒。
开发者审核区沟通。
苹果进行回复，或者苹果主动把状态改为审核中，回到 1。
开发者根据回复进行沟通，回到 2，或者开发者通过二进制包进行提审，回到 1。
过去，以上流程中标红的部分，都会导致审核区的会话历史重置。注意我说的是过去版本而不是现在。
过去这种审核机制带来的问题就是，一旦审核区的会话重置，那么开发者就有相当大的概率被重判本来已经解释清楚的「违规问题」。这带来了两个问题，效率问题和安全问题。
我举个例子，例如一个 app 被识别为 2.3.1，经过艰难的解释，审核总算松口了，转而找到了别的问题，例如 2.1 。这时候距离第一次提审已经过了好几天，开发者不得不重新提交二进制。
而这个重新提交二进制的过程，审核区的沟通记录重置了，也就是说进入了新的与审核沟通的消息环境。这时候新的审核员一上来，因为他没有看过去的审核消息，所以又给你打了 2.3.1……
没错，我们可以笑话审核人员草台班子，但是这种问题其实一点都不好笑，因为比这更严重的是，有时候正因为这种状况的存在，而刚好某个审核在处理的过程中把提审问题累计下来，直接判定封号，就真的不好笑了……
那么新的审核环境是怎样的呢，再看这个图。
新的审核环境是以一次「iOS提交类型」作为会话作用域。
这个 iOS 提交类型，开发者是真正可以控制一次审核上下文对话的，只要你不移除掉提交，那么就可以始终在同一片会话下和审核沟通。
如下图所示，我可以在同一个审核会话下和审核沟通十几次，而且这个过程还可以切换二进制包。
可能有些开发者会觉得，这改动似乎平平无奇。非也非也，对于像 4.3（垃圾邮件）、4.1（抄袭）、2.3.1（隐藏特性）这类敏感的拒审类型，沟通得越仔细越好，沟通上下文的完整性就显得非常重要。
有时候正是因为沟通上下文的重置，导致了苹果审核在马虎的情况下不理会过去的审核情况，而做出错误的裁决，甚至是致命的裁决。
这也是为什么在过去，遇到敏感的拒审，在重新提交二进制包的时候我都特别谨慎，甚至不得不在备注区写清楚来龙去脉，但有时候也会遇到某个马虎审核直接用模板驳回的局面。
而在完整的上下文下，审核效率无疑提高了很多，因为审核看一眼对话记录，很多多余的问题就不用问了，而我也可以放心的继续补齐内容。
例如，在本次审核中，我就是持续和苹果沟通。像下面这样的沟通。
并且在这个过程中反复被苹果拒审，然而每一次都在接近目标，因为在审核区的沟通方向越来越明确，我也能更精准的提交必要的资料。
最终，在沟通达成了最明确的方向后，审核回复了如下文字。
其意思是，我给的资料足够了，他们会根据资料进行一次审核，然后再同步情况。
最最后，审核主动发来这么一段文字。
这段的意思是，他们已经觉得资料审阅没什么问题了，请我再提交一次审核。
这一段有点意思，因为过去他们会主动把审核状态改为 in review，可能不同审核人员的策略不同吧。
于是我提交了审核，半小时内就立刻过审了。
这次的沟通历程比较繁复，然而总体来说还是平滑顺利，要是换老版的 itunes connect 环境，估计为了保险起见我要多费不少心思来保障账号的安全。
最后，小结一下新的审核环境的变化以及带来的开发者策略优化。
第一点，除非开发者自己删除审核状态，否则审核状态及其上下文，直到审核通过前都可以保留，同样保留的还有对话记录。而如果开发者撤销了，那么后续的审核状态会新建立，那么因为没有保留对话，很可能又要重复解释了。例如下图就是我手贱撤销了审核状态，导致提审效率大减。
第二点，开发者尽量结合对话的上下文进行有效的交流，不要车轱辘话，如果之前解释过的，就说「如前所述」（注明会话时间点），审核人员再怎么木，也是会去翻阅的！
第三点，不要急于想当然自己定位问题，多做一些必要的讨论，欲速则不达。
一些有效的沟通原则，我写进我的付费集合《苹果新审核区提审的最佳高级实践》里了，但是坦白说并不建议平时审核顺顺利利的开发者阅读，只适合和我一样谨小慎微小心使船的小伙伴。
昨天本来应该发这篇文章的，结果不小心把付费集合的文章当群发了，罪过罪过。今天才补上。
🔗 补充